到目前為止，你發現就算不使用 create-react-app 預先設定好的腳本與 webpack 設定，你的專案依舊運行得十分順利；整包 code 也少了許多你可能從來不會用到的內容跟套件。雖然從零開始搞基礎建設真的有點花時間，但想想成果，這一切似乎還算值得。

然後時光飛逝，距離你上一次從零開始寫已經過了Ｘ個月，你發現公司準備啟動一個新專案了。你有點猶豫這次還要如此硬派地從頭開始？或是應該直接複製貼上，跳過那些基礎建設的部分，直接處理核心開發內容？而這就是今天的主軸：如何處理一個新專案的基礎建設？

本文

左轉複製貼上

如果距離上一次從零開始寫基礎建設不到三個月，個人會選擇直接將這些內容整包複製貼上帶到新專案中。我認為在短時間內「頻繁地從頭開始打造專案基礎建設」不能算是一件很有效率的事情。

並且「不想直接沿用之前寫好的內容」可能還隱含著一個問題，那就是「上一個專案的基礎建設其實並沒有被調整到最好的狀態」，導致用起來不順手，自然也不會繼續使用過去的程式碼。在此情況下，如果能明確定位出開發體驗不佳的部位，建議先回頭翻修那些用起來不方便的部分，再將調整後的內容帶入新專案。

如果你真的很喜歡暴力解，那就盡量在新起的爐灶裡搞定你在前一個專案裏不喜歡的基礎建設設定，然後把這些修改同步回去。重點是把基礎建設調到順手、以及回頭同步。因為修改的困難與痛苦程度通常只會隨著時間增加，放越久就越不會改了。然後一包義大利麵又有機會誕生。

右轉一邊複製一邊檢視

通常事情會是這樣發展。建立好新專案資料夾後，小部分小部分地搬移過去寫好的內容，並開始檢查是否有看不懂、意味不明或是根本無功用的部分。如果距離上一次新開專案已經超過半年，甚至可以順便評估是否可以考慮升級套件版本。

當然，最理想的狀態是這些套件升級以及改動都能回流到你搬家的源頭，除非那包 code 已經進入不再需要被維護的階段、或是升版的好處追不上改動產生的成本（比如已上線且有交易行為發生的產品）。

從零開始

總之完全沒有參考資料，萬事為空，這時也只能從零開始了。

但鐵人賽都看到這了，不考慮抄一下前面分享過的內容，然後進入邊複製邊修改抱怨的路線嗎 (´・ω・)...

總結

總之，個人通常會根據上一次處理基礎建設的時間來決定要直接複製、或是走一個邊複製邊更新的路線。

從頭開始寫設定還是挺累人的，小部分修改的時間、難度壓力都小很多，趁比較不忙的時候回頭檢查基礎建設，其實比動不動大破大立輕鬆很多。

今天也是本次鐵人賽前半部的小句點，希望個人在處理前端基礎建設的心得能對你產生一點幫助。如果有任何讓你感到困惑、或是覺得「這根本不對吧」的部分，都十分歡迎留言交流。

下半場的鐵人賽預計分享個人將原本使用 hexo 建構的技術部落格全部改用 astro 維護的心得。會聊一點 astro 的基本開發方式，也會介紹我在 2.0 版的技術部落格導入哪些內容。有興趣的讀者歡迎繼續關注 (・ω・、)

感謝看到這裡的你。

本文同步發佈於普通文組 2.0